home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19990725-20000114 / 000220_news@columbia.edu _Thu Oct 21 16:57:08 1999.msg < prev    next >
Internet Message Format  |  2000-01-13  |  3KB

  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id QAA03332
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Thu, 21 Oct 1999 16:57:08 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id QAA21829
  7.     for kermit.misc@watsun.cc.columbia.edu; Thu, 21 Oct 1999 16:33:40 -0400 (EDT)
  8. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  9. From: kermit-support@columbia.edu (Kermit Software Support)
  10. Subject: Re: File type attributes in K95
  11. Date: 21 Oct 1999 16:33:30 -0400
  12. Organization: Columbia University
  13. Message-ID: <CMM.0.90.4.940537928.fdc@watsun.cc.columbia.edu>
  14. To: kermit.misc@columbia.edu
  15.  
  16. > I am sending the dialing script and startup files, along with the
  17. > debug.log and packet.log for this problem.  The only other commands
  18. > given to K95 were LOG DEBUG ON and LOG PACKETS ON.
  19. OK...  The login script is the standard thing generated by the Dialer.
  20. Nothing in it would explain any kind of text/binary reversal.  The
  21. K95CUSTOM.INI file is vanilla (but has that odd printer thing which is
  22. not relevant here...)
  23.  
  24. > After sending the file from Kermit-TSO as TEXT, I escaped out and SET
  25. > FILE TYPE TEXT on K95, then connected and sent the same file as binary.
  26. > In each case the file transfer display on K95 showed the wrong type.
  27. > I can't honestly tell you if the problem is new with Kermit TSO 4.3.3, I
  28. > don't currently have access to any older versions.  Previously, I used
  29. > C-Kermit for OS/2 (191?) and Kermit-TSO  (4.3.1 I think - I remember
  30. > fixing the PDS prefix bug).  I don't remember encountering this problem.
  31. I think the mainframe business is a red herring.  The logs show that
  32. mainframe Kermit is doing everything right.  When you send in text mode,
  33. mainframe Kermit announces text, sends legible ASCII text like:
  34.  
  35.  DCB=(RECFM=VB,LRECL=255,BLKSIZE=0)
  36.  
  37. (heavens, JCL!) and K95 receives it as text, in text mode.  When mainframe
  38. Kermit sends in binary mode, it announces binary, and sends raw EBCDIC,
  39. which of course looks like gibberish in ASCII:
  40.  
  41.  ~&@#N~$prvpp#Oaa~-@&D&C&B#~M#NYECFT&#~eB&kSYECS&#~upp&kBSRbIiE&#
  42.  
  43. and K95 stores it that way (after decoding the Kermit escapes).
  44.  
  45. > I have done some further testing.  I created a file with all possible
  46. > hex characters and transferred in al possible modes.
  47. > I found that even though K95's transfer display reported TEXT (Latin1 =>
  48. > CP437), it did not translate any characters on a binary transfer, so the
  49. > problem is probably in the transfer display code, rather than the
  50. > attribute recognition.
  51. That seems to be it.  This is 1.1.17, right?  If I'm not mistaken, we did
  52. fix some bugs in that area, and so our working copy shouldn't do this.  If
  53. you'd like to try it, let me know.
  54.  
  55. > BTW: Can I put in a request for pipe support at the K95 command line?
  56. > It wouldn't let me enter 'SHOW PRINTER > printer.txt' or 'SHOW
  57. > ATTRIBUTES > problem.txt'
  58. This is probably not in the cards any time soon, but of course you can
  59. always scroll the screen back and copy & paste with the mouse.
  60.  
  61. - Frank
  62.